FIG. 1 illustrates a conventional database system 100 including a database 105 and a database client 110. As illustrated, database 105 stores separate internal keys indexed to each record or data buffer. It is noteworthy that the internal keys are not apart of the record or the data buffer of the record, and do not contain useful data, other than for the purposes of organization and retrieval. To retrieve a particular record, database client 110 provides a key 115 to database 105, which in turn searches on it internal keys. If a match is found, then database 105 will return a record 120 indexed to the internal key that matched key 115 provided. To write data buffers or records into database 105, database client 110 may reference a database (“DB”) schema 125, which includes a description of the internal structure or directory system of database 105. In short, schema 125 provides database client 110 with the knowledge necessary to access and utilize database 105.
Since database 105 merely indexes data buffers or records to internal keys, the knowledge and complexity required to run higher level queries on database 105 is pushed onto application developers of database client 110. Furthermore, since the internal keys themselves are not part of the useful data stored by database client 110, but rather independently generated values used simply for retrieving records or data buffers, the internal keys consume additional memory resources within database 105.
In an alternative conventional database system, database 105 itself may contain knowledge of the internal representation of the data buffers or records it stores to perform it own complex queries and indexing. This alternative embodiment pushes the complexities of indexing and queries onto the database developer; however, does so at the expense of performance by adding a layer of abstraction between the records stored and the database clients accessing the records.